【AWS Summit Osaka 2019 セッションレポート】クラウド流 移行プロジェクトの進め方 #AWSSummit

AWS Summit Osaka 2019 のセッション、「クラウド流 移行プロジェクトの進め方」をレポートします。

セッション概要

移行プロジェクトをどのように進めていますか？クラウド移行プロジェクトを効果的、効率的に進めていくためには、クラウドの特徴を理解した進め方が必要になります。本セッションでは、多くのお客様の移行プロジェクトを支援してきたAWSコンサルタントの視点から構成変更の容易さや IaC(Infrastructure as Code)による自動化などといったクラウドの特徴を活かした移行プロジェクトの進め方を紹介します。

スピーカー

アマゾン ウェブ サービス ジャパン株式会社 プロフェッショナルサービス本部 コンサルタント

松本 雅博さん

セッションレポート

概要

• 想定参加者
  • AWSへ移行を検討している方
  • 移行プロジェクトを既に進めている方
• 目的
  • クラウドの特徴を活かした移行プロジェクトの進め方を理解する

移行の進め方と検討ポイント

全体プロセス

• 計画
  • 目的
  • 移行元把握
  • 移行先設計
  • POCの実施 (大事！)
    • 簡単なものでまずは試してみる
    • 難しいものもやってみて課題感を掴む
    • 必ずしも成功しないといけないわけではない、課題を見つけることが大事
    • 失敗を恐れずにトライ
• 移行
  • サーバ移行
  • DB移行
  • データ移行
• 運用
  • AWS運用
  • 移行後の評価
  • 継続的な最適化

計画・ゴールを明確にする

• コストダウン
• 耐障害性
• アジリティ
• 運用負荷の低減
• グローバル展開
• イノベーションの加速

移行目的を具体的なKPIへ

• 移行の成果を判定するためには定量的なKPI設定が必要
• 例
  • ◯年でTCOを◯%削減
  • リリース頻度が◯%アップ
  • 運用作業を ◯％削減
  • ◯リージョンでサービスを開始

二つのアプローチ方法

• クラウドネイティブ
  • 最初からクラウド最適化な設計、構築
  • 早い段階でメリットを享受できる
• リフト＆シフト
  • まずは現状の構成そのままでクラウドに移行する
  • その後徐々にクラウド最適化を進める
• 当セッションではリフト＆シフトをメインに話す

移行実施方法

日本のお客様は段階的に移行される方が多い

1. 移行対象の分け方を決める
2. 分けた対象の移行順序を決める
3. 対象ごとに移行方式を決める

移行対象の分け方を決める

• アプリケーションポートフォリオに分類
  • 横軸にはマーケティング、物流などの種類
  • 縦軸には戦略的に使うのか、一時的に使うのか、誰が使うのか
• 各アプリケーションの特性を把握する

移行順序を決める

影響度評価マトリクスを利用する

• 縦軸
  • どんなユーザーが使うか
  • ユーザー数、アクセス数
• 横軸
  • 影響度（停止した場合のインパクト）
• 選び方
  • リスクの低いものから
  • ビジネス効果の大きいものから

移行方式を決める 6"R"

• Re-Host そのまま移行
• Re-Platform OSまたはDBの変更やアップデート
• Refactor クラウドネイティブなアプリケーションへ書き換え
• Retire サーバやアプリを廃止する
• Retain オンプレミス環境で引き続き運用
• Re-Purchase アプリケーション、ライセンス買い替え

Re-Host

• OSやアプリケーションに変更を加えずそのまま移行

Re-Platform

• OSまたはDBの変更やアップグレード
• 例：DBをRDSに置き換える

Refactor

• 移行時にクラウドネイティブなアプリケーションへ置き換える
• 例：REST APIをAPI Gateway/Lambda/DynamoDBを使った構成に変更する

移行方式を決める

• ビジネス価値と移行コストで6Rをマッピングしてどれを使うか決める
• 以下順に徐々にビジネス価値も移行コストも上がる
  • Re-Host
  • Re-Purchase
  • Re-Platform
  • Refactor

移行時によくある課題

• アプリケーション
• 性能クラスタ
• OS
• ハード
  • プリンタなどの周辺機器
• ネットワーク
  • 物理的なネットワーク機器

フレームワークによる移行先の設計

Cloud Adoption Framework

• https://aws.amazon.com/jp/professional-services/CAF/
• 企業にとって効果的なクラウド導入を促進
• AWSの実際の経験に基づくもの
• ステークホルダー視点からの6パースペクティブ

Well Architected Framework

• https://d1.awsstatic.com/International/ja_JP/Whitepapers/AWS_Well-Architected_Framework_2018_JA_final.pdf
• サービスをどう組み合わせて、どう設計すれば良いのかへの回答
• クラウドアプリ設計における考え方とベストプラクティス
• アーキテクチャを評価するための一貫したアプローチ
• クラウドの設計原則
  • 必要なキャパシティを勘に頼らない
  • データを計測して、実際の負荷に応じたリソースを設定する
  • などなどが記載されている

移行/対象となるワークロードの移行種類

• サーバー
• データベース
• データ

移行関連サービス

• 色々あるので要件に応じて適切に選ぶ

Server Migration Service

仮想マシンの移行を行うサービス

• VMWare、Hyper-Vの仮想マシンを移行
• エージェントレス

Database Migration Service

マネージド型DB移行サービス

• 既存データベースを最小限のダウンタイムでマイグレーション
• 同種はもちろん異種プラットフォームの移行にも対応

Data Sync

• オンプレストレージとクラウドデータ転送をシンプルに、自動で、高速に実行するオンライン転送サービス

Snowball/Snowball Edge

ハードウェアアプライアンスによる、オンプレからクラウドへの大量のデータを移行するサービス

• 回線に依存しないデータ転送を実現
• 申し込むと、AWSからストレージが送られてくる
• 専用の物理アプライアンスを用いたデータ移行が可能

運用

マネージドサービスで変わる運用

• オンプレでは全てをお客様が管理する必要がある
• 仮想サーバではOSパッチを当てるより上位の部分のみ管理
• マネージドサービスだとアプリケーション最適化に集中できる

移行計画を評価する

• 移行計画時に建てた定量的なKPIを元に評価
  • ◯年でTCOを◯%削減
  • リリース頻度が◯%アップ
  • 運用作業を ◯％削減
  • ◯リージョンでサービスを開始
• ここまでリフト＆シフトの話

• クラウド最適化がその後に必要

クラウドの特徴を生かした移行プロジェクトの進め方

オンプレミスでの制約

ハードウェアを持つことから生まれる制約

• システムリソース
  • 物理的なものを持っているので調達に時間がかかる
  • 容易に追加、変更ができない　
• マニュアルオペレーション
  • 手作業前提の管理手段が多い
• 建物やスペース
  • データセンターに行かないと作業できない

ハードウェアの制約をもとにソフト面の制約も生まれる

オンプレミスでの進め方

• ウォーターフォール式
• 手戻りが発生しないように机上でしっかりチェックする必要があった

AWSによる制約からの解放

• 俊敏性
• コスト削減
• 弾力性
• 貴重な作業に集中できる
• 分単位で世界に展開可能

作りながら要件と設計を固める

• 実験を繰り返す
  • 設計
  • 変換
  • 移行
  • 運用
  • 最適化
  • これを繰り返す
• 自転車に乗れるようになった時と同じように、何度もトライしてみることが大事

動くものを確認しながら進める

机上でのみ検討するのではなく、実際に試す

• イメージが明確になる
• FBをより早く得ることができる

推測ではなく、実測する

机上検討でなく、実際に試す

• 実測値に基づいた性能上限の把握
• 現実的な目標復旧時間

必要な時にリソースを拡張する

従量課金のメリットを生かす

• 普段は機能テストをできるぐらいの最小リソースで
• 本番相当のテストをやるときだけ、スペックを上げる
• さらに休日はリソース停止する
• 複数環境を用途別に用意する
  • 実施するテストごとの環境を用意することで、テスト環境を使う待ち時間をなくすことが出 来る

インフラのコード化

• Infrastructre as Code(IaC)
• バージョン管理
• アプリケーションのように、インフラを管理することができる！

繰り返し作業の効率化

• より実験を行いやすい仕組みを作る
• 手作業からの解放
• 重要な作業に集中できる
  • プロジェクトを進めるためには多くの時間がいる
    • 人手を解放できる仕組があるのであれば、それを使って時間をつくり、トライしていく

まとめ

• フレームワークやベストプラクティスを活用しよう
• 要件と用途に応じてツールを使い分けよう
• プロジェクト実施中にもAWSの特徴を活用しよう
  • プロジェクト実施中にもAWSサービスを使って時間をつくり、その時間でプロジェクトを遂 行する

感想

6R、Cloud Adoption Framework、マトリクスで検討など、知らない知識を色々と得ることができてよかったです。また、「すぐに試せる」ことはクラウドの大きな魅力の一つですが、移行においてもその部分の活用が非常に重要であるなと感じました。

参考情報

• アマゾン ウェブ サービスによるクラウド移行